NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/750

Internet Message Format | 1996-08-06 | 3KB

Path: fido.asd.sgi.com!austern
From: [e-mail] (Fergus Henderson)
Newsgroups: comp.std.c++,comp.std.c
Subject: Re: Array function params and const qualifier
Date: 15 Apr 1996 09:36:48 PDT
Organization: Comp Sci, University of Melbourne
Approved: [e-mail]
Message-ID: <4kr7qv$[e-mail]>
References: <4ke06a$[e-mail]> <4kjqqa$[e-mail]> <[e-mail]>
NNTP-Posting-Host: isolde.mti.sgi.com
X-Original-Date: 14 Apr 1996 16:06:55 GMT
X-Auth: PGPMoose V1.1 PGP comp.std.c++
    iQBVAwUBMXJ7IEy4NqrwXLNJAQHJ3gH/UfWegKGXLfDv9GDiNViLnlPcBvGHzisA
    CgSS+LRNbDvvq+X8/9Iz7yqltyGnIp1/P7qtv4khyHGRrnD4HZVb1g==
    =c59c
Originator: [e-mail]

[Note: this article is crossposted to comp.std.c++ and comp.std.c.]

In comp.std.c++, [e-mail] (Jason Merrill) writes:

>>>>>> Steve Clamage <[e-mail]> writes:
>
>> Adel El-Beik <[e-mail]> writes:
>>> I have a question concerning MSVC++ v.4.00 and the April DWP C++.
[...]
>>> C:\array\array.cpp(16) : error C2664: 'func' : cannot convert parameter 1
>>> from 'long [2][2]' to 'const long [][2]' (new behavior; please see help)
>
>> You have run into effectively the same rule that prohibits implicit
>> conversion from "T**" to "const T**". That prohibition is not new,
>> but is in the ISO/ANSI C standard, and has not been changed, since
>> it would open a hole in the type system.
>
>But converting long (*)[2] to const long (*)[2] is more like converting
>long ** to const long *const * than it is like converting long ** to const
>long **, because there is no way to modify the array -- there is, in fact,
>no array entity in memory, only two longs.  A long (*)[2] points to two
>longs, whereas a const long (*)[2] points to two const longs.  I don't see
>a constness hole there.
>
>I suspect this is an oversight.

Yes, but the oversight is in the implementation, not in the standard.
The conversion in question is allowed by the draft C++ standard.  (See
my other post to comp.std.c++ in this thread for a detailed explanation.)
The conversion is also allowed by a variety of other implementations,
including cfront, gcc, and SGI C++ (EDG).

Interestingly, even though this conversion is presumably disallowed by
the ANSI/ISO C standard, many supposedly conforming C compilers fail to
issue a diagnostic for it.  Of the six I tried, only two issued any
diagnostic, even with all the appropriate options for selecting ANSI
conformance and enabling warnings.

Compiler    Options                        Diagnostic?
--------    -------                        -----------
GNU C        gcc -ansi -pedantic -Wall            No
SGI C        cc -ansi -pedantic -fullwarn -wlint,p        No
DEC OSF/1 C    cc -std1                    No
DEC C        cc -std1 -migrate -check            No
Sun C        cc -Xc -v                    Yes (warning)
LCC        lcc -A -A                    Yes (error)

--
Fergus Henderson <[e-mail]>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:[e-mail]
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:[e-mail]
]